REMARKS 

Section 112, Paragraph 2, Rejection 

The first Section 1 12 rejection on page 2 refers to enablement and talks about "the 
bandwidth utilization without using the fetch engine is critical or essential to the practice of the 
invention, but not included in the claims." Thus, this would appear to be a Section 1 12, second 
paragraph rejection. See M.P.E.P. 2171. The paragraph also cites the Mayhew case. The 
paragraph further states that the applicant claims to transfer pixel data at a given memory range, 
without using a fetch engine. But applicant does not specify, according to the Examiner, and it is 
not clear, according to the Examiner, what type of algorithm or method applicant uses. 

Figure 1 of the present application is the prior art. It shows the use of a fetch engine to 
shuttle data between the color conversion engine 106 and the composition engine 104. The fetch 
engine fetches data from the memory 102 and fetches the data back from the memory 102, 
normally to the same location. 

An embodiment of the present invention is shown in Figure 2. There, a serial 
architecture is utilized. See the present specification at page 4, line 3. For example, data may be 
fetched from the memory 102 into a scaling engine 100. When the scaling is complete, the 
addresses for the data may be transformed to write the data to a color conversion engine 106 as 
indicated by the arrow 2. After a color conversion, the data addresses may be transformed so 
that the data is written directly into the composition engine 104. Thereafter, the composed data 
may be written back to the memory 102 as indicated by arrow 4. Operation accomplished with 
embodiments of the present invention may be more efficient than those of the prior art illustrated 
in Figure 1 . 

The applicant shows how to transfer pixel data to a transformation engine, perform a 
transformation on the pixel data, and readdress the pixel data to another memory address range 
without using a fetch engine. See, for example, page 4, lines 18-25. There it is explained that an 
application may write pixels to a range of virtual memory addresses and the passive engine may 
impose the chosen operation. A new remapped memory address is generated and the pixel data 
is written to the new memory location. 

As explained on page 6 of the top paragraph, pixel data written to a specific memory 
range of virtual addresses is not forwarded to physical memory. Instead, the pixel data is 



forwarded to the media target 16. A specific example is also given at page 6, lines 22 et seq. 
Additional examples are provided thereafter. 

Therefore, reconsideration of the rejection is respectfully requested. 

The second 112 rejection apparently goes to defmiteness. It is directed to claims, 34, 35, 
and 48-54. It is pointed out that the applicant uses the term "transfer function" to specify the 
mapping, writing, reading, performing, etc. of the addresses of pixel data. 

However, the pertinency of these remarks is not at all understood. They do not appear to 
be making out any kind of definiteness rejection. Specifically, claims 34 and 35 do not even use 
) the term transfer function. Thus, the rejection is confusing. 

Claim 48 uses the term first transfer function. The Examiner gives a definition of transfer 
function from some unknown source. He then concludes "therefore, in respect to the definition, 
the fetch engine is considered as a transfer function." This simply makes no sense whatsoever. 
Transfer functions are shown in Figure 3. Their purpose is "to receive pixel data and addresses 
from the immediate port target 16, perform a pixel and address transformation, and forward 
output pixel data and addresses to a media port write back engine 20." See specification at page 
5, lines 17-22. Claim 48 calls for storing instructions that enable the system to write pixel data 
* from the first virtual memory location associated with a first transfer function to a second 

memory location associated with a second transfer function. Regardless of how broadly transfer 
function can be read, it must be read with the other limitations in the claim. Those other 
limitations are totally clear. There is no reason why the fact that transfer functions could 
embrace all kinds of different things in different context that cannot be embraced because of 
other limitations in the claim. 

Therefore, reconsideration is respectfully requested. 

The prior art rejection is traversed on the grounds that the cited reference to Mastronarde 
is commonly owned. Applicant's attorney hereby makes a statement to the effect that the 
application and the reference were, at the time the invention was made, owned by, or subject to 
an obligation of assignment to, the same person. See M.P.E.P. 7.0602(1)(2) at page 700-55. 
Since the only basis for asserting Mastronarde is under Section 102(e), the reference does not 
suffice to make out a rejection. That is because it is dated December 1, 1999 and the effective 
filing date of the present application is May 31, 2000. Thus, it can only be a reference under 
102(3) taken into Section 103. Pursuant to Section 103(c), the rejection cannot stand. 
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It is also noted that the present application has a filing data after November 1999 and, 
thus, the pertinent law is 103(c) as it currently exists. See M.P.E.P. 706.02(1)(1) at page 700-51. 

In view of these remarks, the application should now be in condition for allowance and 
the Examiner's prompt action in accordance therewith is respectfully requested. 



Respectfully submitted, 
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